# Removing Developer Friction in the AI Era

**Podcast:** The InfoQ Podcast
**Published:** 2026-03-02

## Transcript

If you're the kind of senior engineer, architect, or technical leader who people look to for what's next, QCon London is probably on your radar.
Join us in London from March 16th to the 19th, where we go deep on the topics that matter, like the architectures you've always wondered about, engineering productivity and applying AI in the real world.
This isn't about trends for their own sake.
It's about getting practical insights from senior practitioners to help you make smarter calls on where to invest your time in tech.
With software changing fast, QCon London is a conference that helps you lead the change.
Learn more at QCon London.com.
Hello, and welcome to the InfoQ Podcast.
I'm Thomas Betts, and today I have the privilege of speaking with one of the most prominent and important minds in DevOps and developer productivity, Dr.
Nicole Foresgren.
She has led productivity efforts at companies like Microsoft, GitHub, and Google, and is the author of two best-selling books, Accelerate and the second edition of the DevOps Handbook.
Her newest book, Frictionless, talks about identifying and removing developer friction.
Now, back in November, she spoke about that subject during a keynote at QCon San Francisco.
And so that's what we're gonna be discussing today.
Nicole, welcome to the InfoQ Podcast.
Thanks so much for having me.
Now at QCon, one of the things I remember you talked about was this emphasis that developer productivity is about more than just faster builds or better tooling.
We need to look at those friction points that constantly are slowing us down.
Can you explain why talking about friction is a useful way to frame the conversation about DevEx and maybe give us some examples of what you mean by friction?
Yeah, absolutely.
So I think friction can really help us think about how to improve and look for the best areas we can improve development, right?
Like traditionally, you could look at processes that were very manual or require to light a process, because many times those are very fragile and they're going to break.
The same holds true right now with AI, right?
It can surface in different ways, right?
Some things just show up like magic, right?
All of the code uh generation completion that we're seeing right now, but that can also end up creating additional friction points in buildup, whether that's through uh launch processes or code review or things that used to be manual around release and deploy, which is common in many companies.
Now we have this massive backlog, right?
And so things that are friction are often good indications of where things are brittle and possibly about to break as we start to increase load and speed.
When you talk about things that are brittle and about to break, that's not just on the developer's machine or that one service.
It can be like a company wide problem.
Like how does it affect everything?
Who needs to care about DevX?
I think there's one of those the hardest problems in software is naming things and developer experience sounds like, oh, it's just what that coder has to deal with.
But it's a bigger problem.
So how do we make the other people see this problem and how is it affect us as a company more broadly?
That's a really good point.
And I think you know, DevX can be a little challenging there, right?
It can be development friction, it can be value delivery.
But the reason more people should care is as we keep telling executives or as they keep reading, you know, as leadership is reading all of these, you know, bombastic headlines saying that we can spin up entire new uh products and features in an hour and deploy them out.
That's exciting, not entirely real.
But where that's the case, I think that's where it can be really insightful and informative to leadership is if we want to get on this fast path, if we want to be able to leverage AI to do all of these incredible things, we need to look at some of our systems and processes because right now a lot of that is centered around uh developers or kind of that development pipeline, that development experience.
But like you point out, it's not always developers.
It could be a security and compliance review, right?
Where historically uh there was a big back and forth, maybe there's a little bit of security theater where you said no and you negotiated for a few weeks.
That's really, really tough now and now overwhelming, already understaffed many times security and compliance teams.
Or what does release and launch look like, right?
I know many large companies right now that manually select a candidate build and then run it through test and run it through canary.
And anytime you have a bunch of manual work and handoffs and unique decision points, the more you increase load and friction, the more something like that can break.
Like, like you said, it's not just a build, yeah, it could be an approval process that is brittle and breaks.
And then the business cares because we're seeing things change so rapidly, right?
I mean, some of the latest models this morning are doing things that they couldn't do three months ago, two months ago.
And so if we're trying to keep up with the pace of competition and the pace of the industry, even if it's just accelerating some of our feature development, any additional friction highlights things that are slowing us down from our work, but also these kind of potential fragile breakpoints.
Yeah, I think it goes to the idea of things that move at the speed of humans versus the speed of computers.
And we've had a lot of processes developed over the years that work fine at the speed of humans.
Like it takes a few days to go through the email process and that's fine.
And I can concentrate on other faster things over here while I'm waiting for that to go to the background.
As AI and other automation is permeating everything.
It's not just I can write code faster, but I can you know create user stories faster.
All of that gets compressed, and now the whole process starts working at the speed of computers, if you will.
And that's where that friction, you rub against it faster and faster and faster, and that starts a fire.
Exactly.
And especially now that you know we're seeing so much interesting and exciting development in a gentic workflows, right?
It's sort of like builds used to be slow.
So we sped up the builds and then we finally parallelize the builds so that they could kind of be running concurrently.
We're seeing the same thing, right?
It's no longer one person and an agent or one person and a couple of agents.
It can be a developer orchestrating a bunch of agents that are then kind of orchestrating their own work and solving their own problems.
And so any friction point really is amplified.
Yeah.
Um, how do we start measuring this stuff?
What are some of the metrics that we've had in the past?
And do they still work with all this changing to go to an age of AI where there's just more automation?
Do we have the same metrics or do they change?
This is the big question, right?
Uh, I think some of the metrics will remain the same.
Some of the metrics will definitely change, right?
Uh, lines of code is a good example of a metric that was never good.
And it was awful.
But it was always brought up.
Now we're in a in a space where, on the one hand, lines of code isn't complete nonsense metric, right?
Because with a reasonable prompt, I can generate hundreds of lines of code.
On the other hand, it might be useful, but only in very certain contexts, such as what does our code base look like and how is that evolving over time?
And what does that mean for current and future model tuning and model training, right?
Because if we're tuning models on uh historical code bases that were architected and designed and coded a certain way, or we have assumptions about that, what does that mean when maybe soon, you know, a much bigger proportion than zero, at least uh percent of our code bases was machine written, right?
What's that mean for kind of feeding that loop and for a bunch of folks in ML and AI?
We know that the data that you put in is just amplified.
And so something that we might not catch in our initial data and training and inference set can turn into something kind of unexpected.
So that's you know, one example of a metric.
And I think uh there's no one metric that matters, right?
A lot of the frameworks that we have from before are still quite relevant today.
So if we look at Dora, Fedora focused on the pipeline.
It was uh speed, you know, lead time, how long it takes to get through, it was deployment frequency, it's kind of the volume for set period of time.
We're looking at uh change fail rate, which is a quality metric, uh, MTTR, which is recovery.
Now, so back in the day when I started uh a bunch of that work, that was one of the best things we could do is really instrument and engineer the pipeline, right?
The software development pipeline.
We could uh reduce variability, increase predictability, but many of these frameworks still apply across all of our product development work, our software delivery and feature work, right?
Because we can go back up into ideation, we can go into implementation and coding, we can go into production and speed matters and throughput matters and quality matters, and you know, that can help us evaluate our process.
If we're looking at developers or developer productivity, space is a good framework here as well, right?
We can look at satisfaction.
Is a developer satisfied with the tools that they have and the pipelines that they have?
Performance, that's our quality outcomes again, right?
What's the what's the outcome of a process?
A is activity, what are all of our counts, lines of code, which is not great.
Number of commits, uh, number of PRs, number of reviews in a time period, right?
Communication and collaboration.
Where are people getting most of their information from, or how can our systems communicate?
Are APIs holding up fairly well?
And then efficiency and flow, how long does it take?
I think there's probably an opportunity to extend a couple of these.
One is some of this may be true for agents as well, right?
How easy is it to use for an agent?
Uh, what's an agent satisfaction?
We might not ask them, although we might, but that might surface through different types of friction, right?
We may also want to add a couple dimensions.
Trust comes to mind here, right?
Trust is, it's always been important.
I know in the sysadmin community, we we have always centered on trust, right?
Sysadmins and SREs.
Now developers are thinking about it more because they used to be working in fairly deterministic systems.
Uh, and then cost, which cost has always been a thing, but now we're having to make real explicit trade-offs between what's our compute cost, what's our capacity?
Do we want to deploy a thousand agents to do a hundred things to replace a person if then all of our systems fall down?
Uh-huh.
There are a lot of metrics that I guess this is a long version of I I don't have an answer for a specific metric because it will really depend on your environment and your context and what data you have available, but also what questions you're trying to answer.
Yeah, I think you're what you're getting to is we're trying to measure productivity.
Like again, we go back to we call it developer experience.
And if we have better developer experience, and I think your keynote was called like uh from friction to flow, how to great DevX makes everything awesome.
It's like, okay, we have this, but with developer and the developer experience in the name, you keep thinking like that's the thing we're trying to improve.
And it's always been about the bigger picture.
It's always been about software delivery, and that's what we're trying to do.
And and I think that's a good point, right?
The systems view gives us better insight into what's happening, even if when we start, we might focus on developers because that's where we can get some early signal.
But it's always about a system, right?
A developer is always working within a system, whether that's a manual system, uh a purely manual system, a system built on mainframes, a system that's highly automated in the cloud, or now a system that uses possibly a bunch of AI agents and AI tooling.
Yeah.
And we'll go into your example of uh lines of code being a horrible metric, it was sometimes uses that that stand-in proxy for productivity, like, oh, he's able to write a hundred lines of code a day versus 10 lines of code.
I'd rather have 10 perfect lines of code that we actually use versus 10 hundred lines of crap.
Right.
And sometimes the right thing to do is to delete code, right?
Like, like how do you measure that?
Right.
But the if you're looking at the goal of the system got delivered and the system remained stable and didn't have downtime and were able to make changes, lots of little changes very quickly.
Being able to measure that comes back to, well, it's still called developer experience, but it's like all of these other factors.
And I want to poke on your idea that I think you just kind of sussed out was um asking the agent about their developer experience.
Like the agent, if you have a coding agent, you ask them, how do you think it's going?
Or are you asking them to like help me summarize my metrics and help me summarize Dora and whatever else?
Well, I I will say right now I am not asking agents, but there might be a world where we do that quickly, right?
But by the time this gets released, we may be in that world.
But I do think there's an opportunity to ask, right?
Ask, whether like in words or take a look at some of the data points that speak to how agents are developing and delivering code to look for the things we look for when we talk to people, right?
Like what's really difficult with what you do?
What do you swear at all the time?
Right?
Do we see a particular process or something that agents keep having to retry several, several times, right?
Do we see friction showing up somewhere?
Or we can ask them, right?
We can find out what the outcomes are, right?
We can see, we can see kind of the downstream impacts of their work or what they're able to deliver.
And so I think there's an opportunity to maybe kind of interrogate the context of agents and AI which they work, which will speak to both how well the agents can do things and how well we're kind of equipping them in our systems, and also let us ask and think about better ways to equip and enable devs to answer these hard, creative, challenging problems that computers aren't ready for yet.
Yeah.
And that gets, I think back to I wanted to ask about just how workflows are evolving.
We're, I think we tend to focus on the AI coding agent.
Like that's the easiest thing.
I've got GitHub Copilot, there's other things, clogged code, like this writes code for me.
And it moved from write this function to I ask the agent to do the work and it thinks about it and then solves it.
That agent model is moving throughout the software development lifecycle.
Like we've got product management agents that sit next to the PM to help do that, the the scrum masters or other people that are helping to manage the backlog or write the stories or break things down.
They're showing up in all these different ways because it is fundamentally just talking about language.
Large language models are good with coming up with the language.
I think it was the C in in space you talked was communication and collaboration.
Yeah.
That's what I want to ask about is how do we take what we've been trying to do with getting humans to communicate better?
And does that naturally just move to if there's an agent in the loop?
You have a good communication pattern, that's going to help you use these agent tools.
I suspect it will, right?
And like here's here's one example you kind of touched on, right?
Which is breaking down work, providing very well, clearly structured requirements to engineers for engineers to implement.
And we know there's there are differences between very clear requirements and clearly design docs.
And then there's much more ambiguous docs and like what level of an engineer can handle that and what level of engineer we would hand that to, and also, or just the challenge of having like a lack of clarity in docs.
Well, now, if we have very, very clear design docs and feature docs and feature specifications, that communication, just like it was higher fidelity with a person, is now also higher fidelity with an agent.
Because, like you said, it comes down to language, right?
So the better we can communicate and specify, and that's one example.
It can also be having more clearly defined documented APIs.
So when an agent needs to use it, or internal libraries that aren't really externally documented, because it's it's a very kind of one-off thing inside of a company.
Sure, a lot of devs were probably kind of fine with it if they used it several times, if they knew it's edge cases, if if they knew where the dragons were.
But now, you know, you've got a junior level dev who can kind of do senior level things but needs a lot of guidance.
And so this can also speak to APIs and and how our systems communicate.
Yeah.
Yeah, I think if you had good system boundaries where how do the systems talk to each other are the same ways the teams talk to each other, the same way that the organization is structured is the way your software is structured.
Conway's law comes into this.
I don't think anyone's written the AI corollary to Conway's Law yet, but it still applies.
Like if you break up and have a bunch of agents helping your teams, and that's how you're structuring your organization.
It's like, oh, we have these people, and they each have this agent that sits down and helps their role.
That's going to show up in your architecture, I think.
Yeah.
And you know, for a couple years now, we've been talking about how on the communication side, how AI is impacting communication within and among teams, right?
And how we want to think about that and what is good and what is not so good, right?
There are a lot of cases where we see that a junior dev would historically go to the senior on the team and ask lots and lots of questions, especially when they're onboarding or when they're learning a new code base or picking up a new project.
And that's great, right?
I think one of the best things a senior engineer can do is unblock people on the team.
It's also a challenge.
I've had senior engineers on my team that that's all they can do and they feel a sense of pride in it, but they're doing so much unblocking, they don't get to do much of their own technical work.
And that's like that's kind of tough, right?
Because they're very proud of one thing and a little sad that they can't do another.
Well, now we're seeing that a lot of engineers are going to AI first.
They're asking questions.
And this can be good because it can free up some of our time, but it can also end up leaving you down weird trails and rabbit holes and turtles all the way down, and you end up in a weird spot where you never thought you'd be, right?
And so we can also think about are there good checkpoints for asking an agent or you know, having a conversation with an AI chat bot for long enough who knows your code base.
And then when do you pop up and could kind of confirm and verify your plan and your findings with someone on your team who really knows the code base.
Yeah.
And I think that that new person on the team, new person at a company, it depends where you're starting off.
Like you're starting off at a startup and there's no code, right?
You've got to build everything from scratch.
There's no examples to lean on.
If there is examples to lean on, you're like, oh, well, here's what you can do.
You can ask the agent, well, help me explain the code that I'm reading.
But if you also have legacy code and you know this isn't how you want to do stuff and you want to move to something better, but there isn't that next example of here's what better looks like, you might get the feedback like, well, this is how it's always done, just keep doing that.
And this matches our pattern.
Yeah.
And whereas the senior is going to say, that's how we did it.
We want to stop that.
We want to do something new.
And that might not be captured yet in any kind of documentation that the agent's going to pick up or the new dev's going to pick up.
So you still need those people involved.
You do, you do.
I think it also kind of spins back a little bit to we need to work in ways that are appropriate to our context, right?
It's very different to be in a tiny sprinty startup and a larger company.
There are also things that will, for I'll say universally, I may take this back in 10 years, universally remain true.
Like good docs, right?
You can be in a sprinty startup, but without a README or basic docs, that is only sustainable for a certain amount of time.
At some point that is going to break, right?
You'll get enough people and that you'll get enough time from when uh the code base was started, you'll need those docs.
And so AI, right now, there's a lot of really interesting and promising AI tools that can take a look at your code and at least help document your code.
That'll remain true moving forward because as we are, you know, prompting or asking for feedback or asking for, you know, agents to do work for us, they will reference the code that we have.
They will reference the documentation that we have, right?
If we're if we're building a rag model, what do we want to be clarifying for them so that when they do work, it is more clear, either for a human or for an agent.
I wanted to take us in a little bit of different direction.
This is some of the stuff you talked about in your keynote and was also in in frictionless book.
That how do you get this to be something the whole company is going to buy into, right?
Like taking it from the idea of I want to remove this friction to getting the buy-in to say we should focus on this, we should invest in this, we have to make it better because these are the things.
How is that stakeholder buy-in changed, if at all?
Or maybe you just start with how does it start without the AI?
How do you go from I have some metrics or I can start capturing metrics to I can tell a story that my CEO and CTO are going to believe?
There are a few things that are gonna remain fairly true, right?
Which is we want to align with the priorities of our business and of our company and our organization.
We want to align with and understand the problems that they have so we can solve those problems.
And so a lot of the time it's about contextualizing the data that we have and the things that we propose to solve those problems, right?
Um, or to align to something that we know is definitely top of mind.
Now that strategy might look a little different depending on where you are in the org and where your org is.
So if you're in an org that this is not on the radar, they don't care, there are other fires to put out, and you're an IC or you're a manager, kind of a first-line manager, then there are certain things that you can do locally to kind of have an impact and you can start thinking about bubbling that up.
You know, at the other side of the spectrum, there's also the case where the CTO or the you know VP of infrastructure has declared developing and delivering software faster and with greater quality and and more reliability and stability is top of mind.
And then you're hired to lead that effort, uh, whether it's a devx improvement or a measurement improvement, that is a little different in some ways in that your audience will be slightly different, right?
Like you will, and your some of your rollout strategies may be a little different.
You'll still partner with teams, but you can kind of think about what teams you want to be partnering with with your work.
You'll still be communicating out.
Your stakeholders might change a little bit, right?
As a first line manager is an I see I'm probably not gonna have one of my first readouts be to the CTO.
But in both cases, we want to align with the business priorities, the business needs, the problems that we can solve, because then it resonates and people kind of they're in a meeting and they're nodding their heads saying, okay, I see this, I understand why this aligns the way that I need it to.
Yeah.
And I just to give an example, what if you had companies saying, oh, our customers are reporting a lot of bugs, there have been a lot of, you know, releases have gone out and issues have been detected by our customers, and that's affecting our quality scores.
We want to focus on that.
It becomes that top level thing.
And if you can say, well, I think one of the ways we can do this, instead of like, well, just don't write bugs, we should look at DevX and how do we improve that.
You can tie that back to, well, how often do we release?
Do we have, you know, daily builds, you know, going to things that are in accelerating the Dora metrics.
Like, if you do it faster, you get better at it.
If you say, oh, we break stuff we shouldn't release for six months.
That just, you know, is fundamentally not true, right?
Right.
Well, and that's a good point, right?
So if you're in a situation where your products and your features, they're not very reliable or they have a lot of bugs, right?
Your customer engagement and your customer feedback is quite low, right?
That is something where you could go to leadership wherever it is you are to that appropriate level of you know, stakeholder and say, I understand that this is a big problem for us.
I understand that there are some things being worked on, right?
You know, this is a high priority.
We're trying to figure out how to address this problem.
One of those ways we can do that is to look at the developer experience, in which case they're like, what?
You can say, yes, because I can roughly look at, I understand traditionally, right, what our software development lifecycle looks like.
And I can identify some of the key areas where these should have been caught.
Let me go take a look because my hunch is that some of these, and you'll probably find this, right, are very manual processes or they're very, very old test suites and flaky tests that have not been cleaned up because it hasn't been a priority.
And so many times for an executive, linking those things as a priority isn't obvious, right?
For those of us working in systems, we can see how a handful of processes or uh gates are directly linked to that.
But if you're not swimming in software all the time, it's not very obvious.
And so just kind of like couching it in that way can be super helpful.
Yeah, I think that goes to the idea that these are friction points, right?
Like we're not saying get rid of security and reviews and safety and all that stuff.
Like just figure out how to make them not block and sometimes recognizing that by adding that extra step that's a security review, you might also be causing this other backlog to come up.
And so we're gonna wait and only test every two weeks because we have to do a manual test.
All of a sudden, a lot more stuff gets in there and you aren't able to test every little change versus I changed two lines of code.
Check that I didn't break that.
Yep, exactly, exactly.
And you know, in terms of like security and compliance review, we can also take, and we've seen this for years, right?
What's all does do again?
We could take a risk-informed approach where for things that qualify as kind of low-risk changes, those can, you know, go through an attestation model, they can follow regular, you know, a prescribed testing model, and that can be very lightweight, right?
And it's it's auditable, it'll be tracked, it'll be followed.
But that should be unsurprisingly, many large companies it is not, and small companies, that should be very different from a high-risk change that we need to make that really requires eyes on it.
It requires a discussion, it requires a lot of people involved.
But if you treat everything the same way, then either your high-risk changes are zipping through a process that wasn't designed for them, or your low risk changes that are probably fine with some automation, are now getting eyeballs and discussions and hours of meetings that aren't appropriate.
And at some point, people are going to glaze over.
So we will make lower quality decisions for those high-risk releases.
Yeah, yeah.
Again, the answer is always it depends, right?
You need context-specific responses, some way to trip and say, hey, this is a high risk, go through the extra process, or this hasn't met the threshold.
This is easy.
Rubber stamp that goes through.
Yep, exactly.
So I think there's still something to be said of how do you go in and say we've captured the data, we've done surveys.
I think your book talked about qualitative and quantitative um measurements, like you can get metrics out of the system sometimes, but they might not be useful, it might just be the things you can get.
Lines of code.
You can get lines of code, does it tell you anything?
Or you can get how often do we release software because we've got, you know, those things hopefully are instrumented.
And the surveys were to gather more of the qualitative feedback.
If you ask developers what sucks, they will tell you what sucks.
They will tell you what sucks.
And I think right now, especially as AI is changing so many things and it's biting inviting so many people to rethink and reinvent what the SDLC looks like, right?
In some cases, a couple of years ago I said there will be a world where we might collapse the outer loop, right?
I don't think we're quite there yet, but we are probably getting close.
In a world where we're going straight from prototype to prod, uh-huh, it's really hard to step back and say, well, I'm gonna only trust system data, because that's what is reliable when for the most, for the most part, we're creating our tools and systems so quickly that we're not instrumenting them, right?
That that is usually not highest on a new uh developer and internal product or even external product builder's list, right?
Is instrumentation telemetry and observability.
The other thing is it's changing so rapidly that by the time you build the instrumentation and get it into the data warehouse or the data lake or the data fabric and do all the calculations, it could be weeks.
And when things are changing that rapidly, it can be very powerful and at least better than nothing, to ask a handful of developers or observe a handful of developers, what is your development workflow like now?
Uh-huh.
What are the biggest blockers that you have right now?
And sometimes it'll be a process, sometimes it'll be a system, sometimes it'll just be a mental model.
They're not used to thinking about things totally differently.
But system data can't surface that, right?
It can't tell us the why.
So sometimes we can we can skip, especially when things are rapidly, rapidly changing.
If we have no data, surveys and interviews and observations are gonna be your friend.
Yeah.
And this isn't a do one thing or do all the things.
It's a matter of getting prioritization, right?
So yeah, it's having a portfolio approach, right?
Yeah.
How do you how do you identify like where should we get started?
If this is our we're gonna actually make an effort, do you tackle a big thing?
Do you take a small thing?
Do you focus on something that's you're sure is gonna work?
Where do you go?
I would say some of this is it depends, but there are some fairly durable guiding principles here, right?
Where to start?
Talk to a bunch of developers.
Always, right?
Because even if you're stepping into a fairly mature program that has metrics and data and numbers, chatting with a few developers will at minimum give you context.
And many times you'll surface additional insights and additional pieces that don't have instrumentation that you would have missed, right?
So that is super helpful.
Uh, we also probably want to start with a quick win, right?
There's often low-hanging fruit.
What can we do to test kind of our understanding of the problem, test one of our approaches, build momentum, get a shared win among the team, right?
Historically, internal infrastructure work isn't always celebrated.
There are some company cultures that do, and I love it there.
Not everyone else is used to that because it's not something that goes to a customer.
So if we can start building that momentum within the team, but also kind of showcasing those wins other places and showing, even if we kind of squint, like what it unlocked or what it will, you know, likely help us achieve by the end of year that we thought was going to be impossible before, that's good.
So once I kind of I've talked to people, I've gotten that quick win.
What comes next?
I think it really depends on where you are in the org, right?
We I kind of alluded to this earlier.
If you're doing this yourself, if this is a grassroots effort, for sure, start within your scope of control.
Who can you talk to?
Can you partner with your team?
Can you do a hack week?
Can you, you know, clear up some paper cuts that are not just like mildly annoying, but also you can see, you have a line of sight to how that impacts several developers, right?
How does that create friction and confusion and slowness?
If you were hired in by, you know, the CEO to fix this, then your scope can look a little bit different, right?
Your stakeholders are a little bit different.
You'll still be partnering with teams to pilot, very, very likely.
But that's also an opportunity where, if you know, like the whole internal build and release system is like broken.
As an IC, that's probably not the best place to start, right?
As an executive, still not the best place to start, but could be a very real candidate earlier on in the project because you have kind of that scope and control across much more of the org.
Yeah, I think, you know, again, it depends.
I've seen um everything from one developer taking like one day for their, you know, it's a hack Thursday.
We just take Thursday off and we do Tech Thursday and we do a little project on their own to a whole team saying we're gonna take a day or a week, to actually an entire company that said we're gonna dedicate a week.
We gave Chat GPT to everyone, we got an enterprise license, take the time to learn it.
And every department, you know, from programming to marketing was working on their own way to leverage these tools.
It's one of those things like if you figure out like this worked for a small group, can we make it a slightly larger group?
Can we make it company wide?
Is there that type of adoption?
Um, but again, your mileage may vary based on who you are and what you're trying to do.
And the team and the company culture, right?
So it's again, it's it's a tough one of those.
It depends, but most people in the space, right?
Engineers, PMs, we're very smart, right?
We're pretty good at taking kind of the pulse of the org and what we think is going to fit.
And so that's why sometimes I'll reflect back and we do in the book, right?
Here's a handful of things you can do.
Pick the one that is going to resonate with the most within your company.
Pick the one that won't be just a complete opposite of what the culture says, right?
Find one that's a good fit because that will also help kind of build that momentum.
I know you like your acronyms, and one that I have learned from the book was uh Rice or the quick rice technique for how to prioritize improvements.
Can you talk about that a little bit?
Yeah, absolutely.
So rice is a way to kind of think about prioritizations.
Uh PMs use it all the time in product.
And when we do this, when we when we do RICE, we'll do reach, right?
Like how what's your total addressable market kind of?
Kind of, so how many developers inside the company are, you know, impacted by this particular project or friction point?
Impact, how big do we think that impact will be, right?
Will it be on the order of seconds or minutes or weeks?
Confidence.
How confident are we that we can achieve this thing that we're trying to fix or we're trying to remove?
And then effort, you know, how hard will this be, right?
How long will it take now?
In traditional rice, what we see is people using, and we we outline this later in the book as well.
Numbers, right?
So come up with numbers, do a calculation.
We want, you know, R I C divided by E, right?
Because you want like the highest payoff for the for the lowest amount of effort.
Quick rice, though, can at least be helpful when we're just getting started.
We're kind of looking for a quick win and we can just hunch it, right?
Is it high, medium, or low?
Because many times as we're we let we probably have three or four or five candidate projects, right?
I'm sure someone will say, I know this, we'll fix it.
Cool, right?
Go ahead and throw it on the list.
When you have your interviews, uh, when you look at the data, you'll probably have a couple candidates.
Quick rice can help with that because we can just say, okay, this one's high, this one's if you're high across RIC and low on E, that is probably a pretty good candidate for starting.
If you're low on reach, low on impact, low on confidence, and super high on effort, probably not the best place to start.
Unless, again, context, maybe you're in a research org, right?
Maybe you're doing RD and you're supposed to time box something for a month or a quarter to try to do things that people think are impossible.
Yeah.
Quick rice is the gut check, but I did remember getting to the algorithm of here's the simple math, but you have to come up with numbers.
And that did seem like, okay, I've got to do a lot more weighting of everything.
Um, I'm not gonna finish that in five minutes.
I'm gonna spend a couple days on it.
Right, exactly.
And, you know, again, very contextual.
Some organizations, like they need the number, they want to see the calculation, they want the math.
Sometimes, though, you can say, these are the things that I wanted to evaluate.
And sometimes, and later when we do kind of the more detailed rice, we include a handful of additional factors you might want to consider, which is uh like how is it aligned with the organizational goals, right?
What what other type of uh a handful of devx concepts do we want to think of in addition to just you know reach and impact?
Because that can also speak to the ability to get momentum, right?
Is it closely aligned with an ongoing well-funded effort?
That's good to know, right?
Because if if it's kind of on the borderline, that would probably nudge you over.
Have you had any good luck with using LLMs to help you write this justifications and write that communication to the various stakeholders or help you ask the right questions?
Yes and no.
I will say that I have found it best if I start with a pretty solid bullet point list, right?
At least a rough draft.
And then kind of, and then I try to nudge it to like fit my voice and pick up things that like it kind of missed or like it it said the thing and it used the word, but that's not what I meant at all, right?
And then I found it really useful to do a couple things, right?
So once I have the message that I know I like, maybe it can help me draft it.
Then I can ask it questions.
What have I not considered?
What are the holes?
What are the criticisms I should be ready for?
Who will be my likely supporters and who will be my likely detractors?
And then I can take it and I can ask it to help me with comms which we are historically bad at comms but we need to treat this like a product right is we can't field it dreams it we can't just build it and everyone will come.
We can't force them to use it developers aren't going to use anything they've been forced to do right we tried that with CICD tools and everyone just spun up their own Jenkins right so then what I'll say is okay help me frame this for an executive audience these are their key pain points this is what they care about frame this for an engineering director audience frame this for reframe this for ICs and what they care about and so then it can help me think through how I want to communicate this to different audiences.
Now I have done this historically in the past I love this as a tool because many times it kind of aligns with what I'm thinking but every once in a while it'll pick up something or it'll suggest an idea that I probably hadn't thought of.
So it helps me move a lot faster that way.
Yeah yeah I do like when the LLMs help identify my blind spots.
Yes.
And if I can start keeping things written down so that it keeps track of that then like oh yeah I always forget to think about X or somebody's viewpoint, it's really good at saying, you remember you need to talk about this too.
Okay.
Yeah.
I will say one thing here as well is if I go a few iterations down, it it tends to go a little haywire.
Uh, even if I tell it like, no, go back, or no, that wasn't what I asked for.
Or even if it's going well, it can be really helpful to kind of basically clear my cache, right?
Stop that chat, start a new one.
And many, many of our agents right now kind of keep track of some of our context.
But if we want to wipe context, then you've got a fresh pair of eyes, right?
Yeah.
It's great to give it that amnesia and just start over.
So for listeners who want to make an immediate impact, what's one small change, whether that's for an IC or a team lead or a higher leader in the organization that you think they can start with that might lead to some compounding DevX improvements?
Sure.
I think the best thing that almost anyone can do is reach out to a developer.
It can be a peer, it can be in someone in one of the teams that's high priority and ask them, right?
Like, what's it like?
Or, you know, sometimes I like a slightly more targeted question, which is like, what's the hardest part about your job?
What do you swear at all the time?
What's the thing that is unlocking a bunch of stuff for you?
Right.
Because that can at least give you an idea of what you're seeing.
And then you can ask two or three others, right?
And see if there's any similarity at all, right?
You can also reach out and see what work has been done, see if there's any existing docs.
LLMs are also great for this, right?
You can you can feed them a whole bunch of information, ask them to synthesize, because that can surface both what has been done in the past or tried in the past, what worked, what didn't work.
There can also be an implied, this is how it's always been talked about and it's never worked before.
So maybe we maybe we don't do that because it's not going to work.
Or maybe that really is the problem, but we need to phrase it differently because people have anchored on that prior performance.
Now I know this is a topic that you just get really excited about, having written several books on it.
Um, but what excites you about the future of DevX?
Um, how do you see the field evolving over the next few years?
Oh, there's there's so many good things here.
Um honestly, I think the thing that excites me the most is to see kind of the evolving role of engineers and developers, right?
And and we've seen it over years, right?
The the earliest years when we're writing assembly code, we saw mainframes, we saw, you know, cloud, we've seen so many waves.
And I think, you know, when we come up with a new technology, it automates away a lot of the work that we've done historically.
But what it's done is it's opened new doors for us to think about new problems we can solve and new creative approaches we can take.
And so I'm kind of excited to watch that shift happen again.
And I feel like I'm pretty lucky to have seen at least a couple of those shifts in my professional lifetime.
So yeah, yeah, I like that that framing.
I think I I'm glad I don't write, you know, assembly code or do punch cards, but I'm I'm grateful for the people that did that and built the foundation that I get to work on at a much higher level, like I'm solving your business problem.
My first job was on mainframes and I loved it.
I lived pieces of it.
One of the languages that I was in, the text layout was still very constrained to fit punch cards, because that was how it started.
And so while sometimes I'll joke longingly about missing some of that work because it was fun and like a green screen is always great.
I'm really excited that at all of the progress that we've made and where we're headed.
Yeah.
Well, I think that's gonna wrap it up.
Um, so your new book is called Frictionless, uh, seven steps to remove barriers, unlock value, and outpace your competition in the AI era.
Your co-writer was Abby Noda.
Yes.
Uh, and I I will mention there's uh on my website and on his, there's a link to uh a book or you know, the book site where we have about a hundred pages of workbooks linked, and those are free.
They accompany the book.
So we tried to give everyone as many tools as possible.
Or if you can't afford the book right now or don't want to get it, jump in and start trying out the workbooks.
There's enough context there that that you can do a lot with what's already there.
Sounds great.
Well, Nicole, thank you again for joining me today.
It's been a fantastic discussion.
Awesome.
Thanks so much.
Good to see you.
And listeners, we hope you'll join us again soon for another episode of the InfoQ podcast, and I'm not sure if you're not sure if you're not sure.